Just a small update for those that use my little tmux helper: You may want to fetch the latest version from my git repository. At least if you have to deal with a tmux version prior to 1.4 (like, on squeeze), though I really recommend to use a later one. 1.6 from backports or 1.7 (but thats not backported). Fix is small, just a better handling of the non-existing -V option to get the version information.

As most people that are using that funny grey on black thing with the blinking white box AKA a commandline, I do have a heavily configured shell. zsh in my case. Some while ago my old configuration for it started to annoy me and so I set out to redo it. With the basic requirement to be flexible and able to adjust to various zsh versions (back as far as Lenny). I ve set out and looked how others do it and took the (I hope) best bits and put them together in a way I like it. Maybe others want to pick from me, so here I describe a little, maybe someone is interested First - the config is completly inside .zsh. The only thing directly in my $HOME is a symlink from $HOME/.zshenv to $HOME/.zsh/zshenv.home. All in one place, nicer this way. The zshenv just sets ZDOTDIR, so zsh then uses the .zsh itself. Next I am using modules . Well, actually everything is splitted out in small(er) files, so its way easier to maintain. And to overwrite stuff wherever I need to. So my .zshrc just loads those module files - and then goes and checks if it finds the same file inside a series of subdirectories. Those subdirectories are based on the hostname, the kernel name, the username, the domain name and the name of the distribution of the system. And a number of combinations of those. That system allows me, for example, to have a set of aliases defined only on Debian systems (like those to do with apt-get & co). Or define some extra variables if I login to the host franck, domain debian.org. Or whatever more. I m also on the way of doing something similar for all my dotfiles. While I was working at that I finally got fed up with the fact that my prompt, which is based on Phil! s wasn t doing what I wanted it on various of the hosts I access. Thankfully someone pointed me at a change to the grml zsh config: Frank Terbeck rewrote their prompt to make use of the zstyle system. Now that got me going, I like the idea of having the whole prompt easily configurable and changeable. My prompt always has shown slight differences depending on where the shell runs, which meant I had to carefully craft PS1 for every such change, and when one changes something one had to check all the places to adjust them too. No longer. I took Franks work and extended it for me. I wanted to still have a design matching my old prompt (minus colors, I changed color themes anyways), but with full flexibility the zstyle system can offer here. Now I am at a point where

• One zstyle call can change the information or order in my prompt.
• The prompt automagically leaves out information when the terminal width gets under a limit,
• I can have whatever extra information items in the prompt, even if the prompt never defined a default for it. Including running neccessary functions to update those extra items.
• the prompt switches between color and black/white mode with one zstyle change,
• the prompt draws lines differently, depending on the capabilities of the terminal.

As an example, on the ftp-master host my prompt, while otherwise being the same as everywhere else, contains one extra item - displaying the current status of the archive (dinstall). If you want to try it, the setup file is available, but note that I don t give any warranty. :) Works for me . I load it in my Prompts module, while having the prompt setup file in my function path. The 4 commented lines, my testcase, are a nice example of a custom token, though a real life one, the setup for the ftp-master prompt with the one extra item can be found over here. Comments? Bugfixes? Enhancements? Update: Got asked for an example how to use my prompt to fake another. So here is what you need to do to use my prompt setup to imitate the prompt clint, as delivered with zsh:

autoload promptinit && promptinit
zstyle ':prompt:ganneff' vcs_info true
# Alternatively you can set whatever you like it to be.
zstyle ':prompt:ganneff' set_vcs_info_defaults true
zstyle ':prompt:ganneff' colors true
## no right prompt
zstyle ':prompt:ganneff:right:setup' use-rprompt false
## color of brackets depending on variable
zstyle ':prompt:ganneff:*:items:openbracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:openbracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:closebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:closebracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:openanglebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:openanglebracket' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:*:items:closeanglebracket' pre '$ $ SSH_CLIENT+"$ PR_YELLOW " :-"$ PR_RED " '
zstyle ':prompt:ganneff:*:items:closeanglebracket' post '$ PR_NO_COLOR '
## extra date format, and its color
zstyle ':prompt:ganneff:*:items:date' token '%D %a %y/%m/%d %R %Z '
zstyle ':prompt:ganneff:*:items:date' pre '$ PR_CYAN '
## pts. %l instead of %y, also color again
zstyle ':prompt:ganneff:*:items:pts' token '%l'
zstyle ':prompt:ganneff:*:items:pts' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:pts' post '$ PR_NO_COLOR '
## host ends with :
zstyle ':prompt:ganneff:*:items:host' token '%m:'
## and a different style for the rc level
zstyle ':prompt:ganneff:*:items:rc' token '%(?..[%?%1v] )'
zstyle ':prompt:ganneff:*:items:rc' pre ''
## change color for other parts that differ to my default
zstyle ':prompt:ganneff:*:items:user' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:host' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:at' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:path' pre '$ PR_GREEN '
zstyle ':prompt:ganneff:*:items:history' pre ''
## Show the shell level in a different way
zstyle ':prompt:ganneff:*:items:shell-level' pre ''
zstyle ':prompt:ganneff:*:items:shell-level' token 'zsh%(2L./$SHLVL.) '
## And history is just a bold number. Lazy here, not using pre and post
zstyle ':prompt:ganneff:*:items:history' token '%B%h%b '
## And the last part in prompt, a # or % depending on privileges
## Using standard zsh tokens for bold
zstyle ':prompt:ganneff:*:items:privileges' pre '%B'
zstyle ':prompt:ganneff:*:items:privileges' post '%b'
## Now there are two parts not defined by default, so lets create them
## Both are simple existing variables, no need for extra precmd functions
## system info
zstyle ':prompt:ganneff:extra:ostype' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:ostype' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:ostype' token "$ MACHTYPE /$ OSTYPE /$(uname -r)"
## zsh version
zstyle ':prompt:ganneff:extra:zshvers' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:zshvers' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:zshvers' token "$ ZSH_VERSION "
zstyle ':prompt:ganneff:left:full:setup' items \
    openbracket date closebracket openbracket pts closebracket openbracket ostype closebracket \
    openbracket zshvers closebracket newline openanglebracket user at host \
    path closeanglebracket newline \
    shell-level space history rc space vcs privileges space
prompt ganneff

And if you now tell me Uh, thats so much more than just saying /prompt clint/ , then you are right. But then: This way is flexible. As I wrote above, my prompt on the ftpmaster host is different. Actually, my prompt on all machines inside the domain debian.org differs, by having

zstyle ':prompt:ganneff:*:items:host' pre '$ PR_YELLOW '

in the Prompts definition for domain:debian.org. And thats enough to show me im on a .debian.org machine by a yellow hostname, instead of my default red. On the ftpmaster host I have the additional few lines: # Want one more piece in my prompt here, dinstall status zstyle :prompt:ganneff:left:full:setup items \ ulcorner line openparentheses user at host pts closeparentheses line history \ line dinstall line shell-level line flexline openparentheses path closeparentheses line urcorner newline \ llcorner line rc openparentheses time closeparentheses line vcs line change-root pipe space

zstyle ':prompt:ganneff:extra:dinstall' pre '$ PR_CYAN '
zstyle ':prompt:ganneff:extra:dinstall' post '$ PR_NO_COLOR '
zstyle ':prompt:ganneff:extra:dinstall' token '$DINSTALL'
zstyle ':prompt:ganneff:extra:dinstall' precmd jj_update_dinstall
zmodload zsh/mapfile
jj_update_dinstall ()  
    DINSTALL="$ $ (z)$ (f)mapfile[/srv/ftp.debian.org/web/dinstall.status] [2] [3,99] "
 

And woo, thats simple. I think. (There ought to be a way to just easily add the item at a defined place in the items zstyle, but meh, too lazy to look).

So this weekend was removal time, namely Lenny. I started out by getting all the different archives which had a Lenny release placed onto archive.debian.org, namely volatile, backports, security and of course the main archive. Actually, they got put onto one of the two hosts that hold this archive and are now syncing to the other. Today started by removing Lenny from those archives. As volatile is dead as an extra archive that was easy - DSA turned off the machine. Backports and security got all their files removed in one big removal after which I had them forget they ever dealt with Lenny. The main archive is a different story. Due to its size I can t simply remove all files at once. This would break every mirror, as they don t delete too many files at once. For the official mirror scripts that magic number is 40000. Both, backports and security, had less than that for their lenny suites, but the main archive has somewhere around 195k files that need to go away. Slightly more than the limit. For that reason I set out to only delete parts of the files for each mirror push. Lucky our toolset supports this easily, I simply had to declare the lenny suites empty and let our clean-suite tool do its work. Worked flawlessly - if one considers 8 hour runtime to mark the files as delete-able no flaw. Took another two hours to actually delete the first 20000 files out of our pool. The next mirror push will thus delete every lenny related entry in our dists/ tree and some 20000 files out of pool. The following mirror pushes will continue deletion, in batches of 10000, until all of lenny is gone.

By now I am a long time happy user of tmux instead of screen. I started using it somewhere in 2011 and by now I only have one usage of screen left over (direct ttyS0 access for one serial). As usual I have a custom config for it, and if you are interested there is a link for you: tmux.conf. But the more interesting part and why I blog is that I also wrote a little helper around tmux. Ingeniously called tm. And a colleague said I should let other people use it too and place it somewhere accessible. So, err, here it is. Or better, the usage output of it, the actual script has a link somewhere below.

---

tmux helper by Joerg Jaspert <joerg@ganneff.de>
Call as: tm CMD [host]...
CMD is one of
 ls          List running sessions
 s           Open ssh session to host
 ms          Open multi ssh sessions to hosts, synchronizing input
 $anything   Either plain tmux session with name of $anything or
             session according to TMDIR file
TMDIR file:
Each file in $TMDIR defines a tmux session.
Filename is the commandline option $anything
Content is defined as:
  First line: Session name
  Second line: extra tmux options
  Any following line: A hostname to open a shell with in the normal
  ssh syntax. (ie [user@]hostname)
Environment variables recognized by this script:
TMPDIR - Where tmux stores its session information
         DEFAULT: If unset: /tmp
TMSORT - Should ms sort the hostnames, so it always opens the same
         session, no matter in which order hostnames are presented
         DEFAULT: true
TMOPTS - Extra options to give to the tmux call
         Note that this ONLY affects the final tmux call to attach
         to the session, not to the earlier ones creating it
         DEFAULT: -2
TMDIR  - Where are session information files stored
         DEFAULT: $ HOME /.tmux.d
TMWIN  - Where does your tmux starts numbering its windows?
         This script tries to find the information in your config,
         but as it only checks $HOME/.tmux.conf it might fail.
         So if your window numbers start at anything different to 0,
         like mine do at 1, then you can set TMWIN to 1

---

It is mainly useful for using tmux as a ssh-multiplexer and replacement for clusterssh though its happy to do any other tmux session too. As the help text may already have told you, you can use it to list existing tmux sessions (oh, wow!). Honestly, that one is there because tm ls is shorter than tmux ls More interestingly, tm s HOSTNAME opens a tmux session with the first window being a ssh shell to HOSTNAME. Should you later type tm s HOSTNAME again, it will attach to the existing session. But the real kicker for me (and colleagues) actually is the ms subcommand of it. ms being short for multi-session, it is my way of no-longer using clusterssh. Basically you type tm ms HOST1 user@HOST2 and it opens a session with one tmux window consisting of two panes. Showing you host1 and host2 at the same time. And the input to both is synchronized, that is - all your input is send to both of them. You aren t limited to just two hosts, do as many as you wish. Actually, I have no idea if tmux has an upper limit, but I did already have more than 100 hosts open at once. The major limitation there is not tmux - but simply the available screenspace, as all hosts are shown in ONE window! (The one advantage of clusterssh, it uses one xterm per host) This is quite helpful in all kinds of administration work involving clusters - imaging installing a package on 5 hosts of a cluster, you usually want it on all of them - or any kind of situations where one wants to run one command on many systems. As I m already said, I m lazy. And so there is a way to easily define multisessions that one uses regulary, by creating files inside the directory behind $TMDIR, usually $ HOME /.tmux.d. They are simple text files and let you easily define sessions you can then (re)open with a simple tm whateveritsname. And if you want the whole script by now: tm

While going through the NM Process, I spent a lot of time on https://nm.debian.org. At the bottom of the page, there is a TODO list of some new features they would like to implement. One item on the list jumped out at me as something I was capable of completing: IRC bot to update stats in the #debian-newmaint channel topic. I immediately reached out to Enrico Zini who was very supportive of the idea. He also explained how he wanted to expand on that idea and have the bot send updates to the channel whenever the progress of an applicant changes. Thanks to Paul Tagliamonte, I was able to get my hands on a copy of the nm.debian.org database (with private information replaced with dummy data). This allowed me to create some code to parse the database and create counts for the number of people waiting in the various queues. I also created a list of events that occurred in the last n days. Enrico then took this code and modified it to integrate it into the website. You can specify the number of days to show events for, and even have the information produced in JSON format. This information is generated upon requesting the page, so it is always up-to-date. It took a couple of rounds of revisions to ensure that the website was exposing all of the necessary information in the JSON export. At this stage, I converted the code to be an IRC bot. Based on prior experience, I decided to implement this as an irssi5 script. The bot is currently running as nmbot in #debian-newmaint on OFTC. Every minute, it fetches the JSON statistics to see if any new events have occurred. If they have, it updates the topic and sends announcements as necessary. While the bot is running, there are still a few more things on its TODO list. First, we need to move it to a stable and permanent home. Running it off of my personal laptop is fine for testing, but it is not a long term solution. Luckily, Joerg Jaspert (Ganneff) has graciously offerred to host the bot. He also made the suggestion of converting the bot to a Supybot plugin so that it could be integrated into the existing ftpmaster bot (dak). The bot's code is currently pretty simple, so I do not expect too much difficulty in converting it to Python/supybot. One last item on the list is something that Enrico is working on implementing. He is going to have the website generate static versions of the JSON output whenever an applicant's progress changes. The bot could then fetch this file, which would reduce the number of times the site needs to generate the JSON. The code for the bot is available in a public git repository, and feedback/suggestions are always appreciated.

Gnarf. Someone happen to need a new Sysadmin - working from home?

I recently got myself a new host somewhere in that big thing internet. Pretty big one too and I m moving stuff from other machines over there, to get rid of the other ones. To have things nicely seperated I am using KVM, especially as I also have many different people owning a VM on that machine. In the past I was using Xen, not KVM, and there was the nice Xen-Shell available for it, so that those other people can manage their own VM, but not need direct access to the main box. Or any kind of root beside the limited ability properly put within the xen-shell. There doesn t seem to be anything like this for KVM. Nothing, nada. What? Oh well, with lots of use of search engines I finally found kvm-shell, a Shell Script from Michael Kress. It looked like it was about to do what I want - except that it didn t work. So I set out last weekend and made it work. So here, for those who are looking for a similar tool, grab your copy from here. The way to use is easy:

• You want to have local users with this script as their shell
• Then add them to a sudoers so they can run virsh
• Party

Any bugs you find (I m sure there are) are yours to keep - or you can send me a mail and a patch. Same for new features, I m interested in getting more stuff in. [Update]: Actually one could name this virsh-shell too. Or libvirt-shell It should work with all systems supported by libvirt, it is just calling virsh $whatever for most of the stuff it does.

Right, so I am at the BSP in Hildesheim. Arrived somewhere Friday, leave in a few hours, and in the meantime I managed to break all our 3 archives at least once. Yay. But heck, I also managed to get them back to work (with help from the FTPTeam too), so it was a good thing. We are back on one code revision for security, backports and main archive. Security also changed to the newer style of handling the buildd repositories and is now also using daks own method of writing packages files instead of using apt-ftparchive. And while I was at it I also created 3 new sections, got a SHA256SUMS file in addition to the MD5SUMS for the debian-installer images (thanks Joeyh for the quick reaction), enabled DM uploads for backports and implemented various other smaller fixes and cleanups.

OK, this one is meant for Planet Debian...

One of many, many changes in the latest lintian is vendor profiles and, thanks to a heads-up by Niels Thykier, Emdebian will have working profile support in the next upload of emdebian-grip. (The only reason it's not already in Debian is my own fault for not uploading when I thought I had the time to upload.)

$ lintian --profile emdebian-grip drivel_3.0.2-1em1_amd64.deb 

$ lintian --profile debian drivel_3.0.2-1em1_amd64.deb 

E: drivel: debian-changelog-file-missing

E: drivel: copyright-file-compressed

W: drivel: copyright-without-copyright-notice

E: drivel: description-contains-invalid-control-statement

W: drivel: binary-without-manpage usr/bin/drivel

So the em1 version implements Emdebian Policy for Emdebian Grip. Clean for Emdebian Grip, just as the Debian package is clean prior to the changes.

I expect this to dramatically improve the processing of Emdebian packages, both for Grip and for the cross-built flavour, Crush, once that actually starts up.

Thanks to the lintian team for this support. Now if there was some way of backporting this version of lintian to Squeeze, I could also use this at work to suppress really annoying lintian warnings about non-standard suite names. (The whole point of using a non-standard suite name is to keep our stuff separate from the normal Debian/Emdebian stuff for licensing reasons etc.) Update: of course, I didn't check the PTS for lintian before writing that, so hence didn't notice that the backport already exists! Thanks again to Niels for the prompt. I've now got another package to create for work. Update2: Thanks to Joerg Jaspert for the tip that all lintian versions get backported directly from unstable as an exception on ~bpo. The work package is ready, so this is going to make things a lot easier when building stuff on stable.

In other news, the same version of emdebian-grip will include support for integrating Emdebian Grip into Debian itself. This too will use vendor-specific support, this time an internal vendor name which just needs to work on the "buildd".

(It's not quite a buildd, Emdebian Grip doesn't build anything, it's all post-processing. It's just that the processing of Debian packages for Emdebian Grip will look a bit like having a second buildd working on the packages uploaded by the existing buildd. The process itself is still developing...)

When I think about Margarita, I always remember her as a friendly and welcoming person. Like most of the Debian Women members by the way. But she likes to spread some love and organized a Debian Appreciation Day for example. I think I met her in real life for the first time at Debconf 6 in Oaxtepec (Mexico). She deeply cares about Debian in general. She has proven it multiple times with her DPL candidacy and by giving talks like Making Debian rule again. One last thing, Debconf11 is just over and you will see that Debconf4 has had a big influence on Marga. My advice is simple: next time there s a Debconf on your continent, make sure to take a few days off and come to meet us! It really gives another picture of the Debian community. Now let s proceed with the interview. Raphael: Who are you? Margarita: I m Margarita Manterola, a Software Developer from Argentina. I work developing software in Python in a Debian-friendly company during the day, and teach programming at a local university during the evenings. I m married to Maximiliano Curia who is also a Debian Developer, most of our Free Software work has been done together. I only maintain a handful of packages in Debian, I m more interested in fixing bugs than in packaging new software. I ve also been a part of the organizing team of many of the previous Debian Conferences. One of the biggest commitments and the biggest success of my participation in Debian was being part of the organizing team of DebConf8, in Argentina. Raphael: How did you start contributing to Debian? Margarita: I started using Debian around 2000. Soon after we had learned the grips of general GNU/Linux usage, Maxy and I started giving an introductory course at our local university, and became quite involved with the local LUG. At some point in 2002/2003 I became a Debian Bug Reporter : most of my friends would report bugs to me, and I would then write them in the proper form to the BTS. I would also be very attentive about reporting any bugs that I might encounter myself trying to create good bug reports. The turning point in my participation in Debian was DebConf4 in Porto Alegre, Brazil. Being so close to Argentina meant that we felt specially invited to be there, and Maxy and I decided to go to DebConf for our honeymoon. We didn t really know much about DebConf dynamics, but we were really eager to learn more about Debian and become more involved. What happened was that meeting with DDs from all over the world transformed our lives, we became part of the Debian family and wanted to be more and more involved. Soon after that we both started maintaining packages and not long after that, applied to become Developers. The Debian Women project also meant a lot to me. I felt encouraged all along the way, encouraged to learn, to ask questions and to lose the fear of making mistakes. I became a Debian Developer on November 2005. Since then, Debian has always been one of the most important things I do in my life. Raphael There was a Debian Women BoF during debconf. What are the plans for Debian Women in the upcoming months? Margarita: I was not there in person, but thanks to the awesome work of the video team, and of Christian Perrier s typing efforts when something failed, I was able to experience much of what was discussed. One of the many points that came up during the BOF is that many people Want to help but don t know where to start or how to go about it. It s a challenge for the Debian Women project to find a way to allow these people to become involved in Debian through Mini projects or something like that. Another of the subjects that was brought up was the Debian Women mentoring project, which has been going on for quite a while now, but lacks enough publicity. So, we need to reach more people about it, and maybe also improve it with some templates, similar to the New Maintainer templates, so that mentees that don t know where to start have some sort of general path to follow. Raphael: You created very useful diagrams documenting how package maintainer scripts are invoked by dpkg. How did you do it and was that a useful experience? Margarita: I did those diagrams to be able to answer one of the questions in the NM templates, regarding the order of the maintainer script execution. Answering the question in text was basically copying and pasting the part of the Debian Policy that explained it, which wasn t really too clear for me, so I decided to go and make a diagram of it, so that I could really understand it. I did it by the best of all debugging techniques: adding prints to each of the maintainer scripts, and testing them in all the different orders that I could think of. It was a useful experience at the time, because I learned a lot of how maintainers scripts work. I didn t expect the diagrams to become so famous, though, I only did them to answer one NM question, that I assumed most other people had already answered before Raphael: You participated in a DPL election. This is a big commitment to make. What were your motivations? Margarita: As I said, I was part of the organizing team of DebConf8, in Argentina. Which was quite a success, a lot of people enjoyed it and praised the good work that had been done by the local team. During said DebConf8, I had a dream (it was almost a nightmare, actually): I woke up and just like that, I was the DPL. I spoke to some people about this dream and to my complete surprise many said that I should actually do it. After giving that possibility a year and a half of thoughts, during the 2010 campaign I was talked into participating myself as a candidate, and it was a very interesting experience. However, I m very glad that Zack got elected and not me, I think he makes a much better DPL that I would have made. Raphael: What s the biggest problem of Debian? Margarita: I think the main problem that we have is our communication, both inside the project and outside the project. Most of us are very technical people, our skills lay in the technical part of Debian (preparing packages, fixing bugs, writing software, administering systems) not in the social part. And thus, we lack a general empathy that is quite needed when interacting with people from all over the world. Raphael: Do you have wishes for Debian Wheezy? Margarita: Not particularly. I do want it to be a great release with good quality, stable software. I would also like to keep making Debian more and more universal with each release, making it more user friendly, more accessible, and more robust than any other previous release. Raphael: Is there someone in Debian that you admire for their contributions? Margarita: I admire a lot of people in Debian. There s a lot of people that contribute a lot of time to Debian, amounts of time that I can t begin to understand how they can afford. I admire Stefano Zacchiroli, our current project leader. And Steve McIntyre, the project leader before him. Also Bdale Garbee, who s also been a DPL in the past. Making this list I realize that Debian has been blessed by quite a number of great leaders in the past. I admire Holger Levsen, for his contributions to the DebConf video team, that have made it possible year after year for the whole project to participate in DebConf remotely. I admire Steve Langasek and Andreas Barth (etch is still my favourite release). I admire Christian Perrier for his work on internationalization. I admire Joerg Jaspert for the incredible amounts of time that he puts into Debian. And actually, I could go on admiring people all night long. I admire so many people that this interview could become a very boring list of names. I guess it s better to leave it at saying that Debian is lucky to have quite a lot of excellent hackers around.

---

Thank you to Marga for the time spent answering my questions. I hope you enjoyed reading her answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

14 comments Liked this article? Click here. My blog is Flattr-enabled.

I m here at DebConf11 and it started in the worst possible way. First my wife and me had the pleasure of being guests of the Bosnien border police for 11 hours. Overnight stay in a small room in a small building far away from whatever we know. And unknown status when it goes on. Oh fun. And then, after finally arriving here, my Laptop breaks. Stupid machine, why break at the beginning and not at the end of the conf? It heated up, all to 120 C (which I don t believe is good, nono) and then turned off. Came back on some time later, but the graphics card got a kick. The left part of the screen now shows a big white strip all over it. Which doesn t help it at all. Additionally the thing does not want to operate below 70 C anymore. At least it only takes seconds for it to heat up that far. The fans stay off. There is a way to turn them on by software. If i use that way - the temperate quickly climbs over 100 C. WTF? Well. Guess that means I am looking for a replacement. I don t have too many requirements. Basically I want a BIG screen (and I mean big, my current has 17 ) and that it works well with Debian. Reasonable battery life (1.5hours is reasonable for such a thing, anything more is fine. Its NOT a mobile thing to use on trips, for that I have other devices. It is a workstation you can easily take with you) and the usual rest of a good CPU, at least 4GB RAM and >60GB Harddiskspace. Any suggestions?

So lets try this:

So it finally looks like I will be at DebConf11 too. Including my (then) wife (ohwow, feels weird to write this). At least we just booked the flight tickets. There is a small chance that we still won t make it, but for now it looks good. Lucky beings we seem to be - we found flights going directly to Banja Luka, no need to take train from somewhere like Zagreb or so. (Well, for some values of directly, we have one stop included). We will arrive on Friday the 22nd, afternoon and leave on Sunday the 31st, again afternoon. Since DC6 this is the shortest time I had attending DebConf (DC5 I only did DebConf, not Camp, DC10 I skipped entirely). Somehow feels weird. Update: Well, due to some <censored> we now do have to go via Zagreb and an annoying bus trip. Meh. Should make us arrive on Thursday late night, but still annyoing.

The first concrete outcome from the Debian derivatives census is the creation of Planet Debian Derivatives. For those of you who are interested in the activities of distributions derived from Debian, it aggregates the blogs and planets of all the distributions represented in the derivatives census. The list of feeds will be expanded semi-automatically as more distributions participate in the census and maintainers of census pages add new blog and planet URLs. Many thanks to Joerg Jaspert for doing the necessary setup procedures for the addition of the new sub-planet to Planet Debian. I'm glad that it was accepted alongside the sole language-based sub-planet (Planet Debian Spanish). I plan further integration of information about derivatives with Debian infrastructure. My next target will be integration of information about the packages in Debian derivatives into Debian. I hope to work on getting that information into UDD (and rmadison) and the packages.d.o site during DebConf11 and DebCamp. If you are interested in helping out, please add your ideas to the integration wiki page, check out the code and add more scripts to it. If you have any comments or questions about this or any other activities related to Debian derivatives, please direct them to the debian-derivatives list and the #debian-derivatives IRC channel on OFTC. Those of you interested in the other side of the software stream might want to take a look at Planet Debian Upstream, which is run by the excellent Joey Hess. He is also on the lookout for interesting blogs by people writing software that is packaged in Debian. The site is created using ikiwiki, hosted on branchable and editable with an OpenID account.

Like last years initiative from Joey we have another opening for DebConf Newbies . Turns out this year it is me doing the main work for it, so here we are: If

• you never have been to a DebConf, or
• you last saw the conference in 2007 (Scotland)
• you can schedule a week off in July
• fear you might not make it with the normal sponsorship process ( they will never ever pick ME, im too small an ant in this project )

then this is for you. To apply for this funding, email newbies@debconf.org before 18th of June. The earlier you mail, the better, as funding will be given out in a first-come/first-serve way. In your email include an estimate of your travel costs, from where you travel from and the amount you are unable to fund yourself. I also need to know the dates you plan to arrive and leave. Please indicate if you will also need sponsored food and accommodation. (At the time of this writing you can still get sponsored food and accommodation by simply registering with the conference, so if you read this before May 19th please ensure to register NOW). Please also ensure you register with the conference now (see DebConf11 registration, even if your plans are not fully secure at this time. There is no punishment if you can not attend later - simply do not follow the reconfirmation process shortly before the conference.

I just had a talk on How to contribute here in Taipei. The slides are available here in case you are interested.

And here we are again. And we still have energy for one more day (and a half). Barely, but still. And it is actually looking good, we do think we will have a working archive when we are leaving here tomorrow at noon. And compared to last year we won t even need a session until 3AM to make this work (and still have half of the tools not working). Yay. Yesterday had Ansgar fixing up various issues until we set him onto Generate Packages/Sources files out of the database . Which got us some funny quotes later on, like are 3.6 seconds to write a Sources file ok or too slow? (compared to the roughly 90 seconds it takes today). Torsten had various bugfixes (as we all, somehow there is never an end of them) and is currently looking at DSUS , which is the result we got out of a GSOC project. Mark tried to continue the multi-archive stuff but got distracted a lot, we regularly asked him to look at other items and then we also made him restart all the thoughts on it by slightly redefining the parameters for the multiple archives. I myself continued with shell scripting around the buildd autosigning and today I take to check up on all our cronjobs (besides unchecked/dinstall which we know do work) to ensure we can turn them back on starting this afternoon.

Proposals for autosigning were floating around for quite some time. The most controversial parts were how we secure the machines that do the building (and in turn: how do we secure the key) and who's going to manage the keyring (because there are multiple teams involved; such discussions can indeed take quite a bit time).

What we've agreed upon now is as follows:

• All buildds with autosigned must be debian.org machines, which means that they are administrated by the Debian Sysadmins. This involves regular upgrades of the machine, firewalling and monitoring. They are all doing this already (kudos!), so there was no change needed.
• The machines must be restricted so that only a limited set of people may access it. That's done, it's just the buildd admins for the specific buildd and the global group builddadm (plus the admins and the local admin, of course).
• Every host has its own GPG key. Key generation locally on the buildds is eased by having the fine Entropy Key hooked up to provide entropy centrally and distributed to the debian.org machines. Private keys don't need to and must not leave the host. The keys are rotated every 120 days, expiry dates will be used to ensure that and to remind us when rotation is due. Sadly there is no HSM involved. Given the geographic dispersiveness of the Debian infrastructure that's not done easily. Some machines (like s390 racks) would also be unable to connect local hardware.
• The keys are restricted to specific architectures. They are not able to upload any source to the archive. However every binary on the specific architecture can be uploaded using the key, there are no further restrictions on package priorities or the like. They are maintained by the wanna-build admins on ftp-master by signing the armored public keys with their personal GPG keys (instructions available on the list). Thus a trust chain is established: who added or removed which key and when.
• We plan to suppress networking in the chroot soon. This will possibly be done with unshare(1) in util-linux, as soon as we sort out proper localhost networking. This was not deemed a blocker at this point.

Should you have thought we are gone, let me assure you - we are not. I just blog a bit later than I did the last days. Anyways, we did have a good day yesterday. Turns out that, when Ansgar said I don t know much Python so might not be able to do much he actually meant Just point me at problems, no matter how complicated, and I come up with the python code to fix them . And so we did point him at various problems and got lots of code. And we intend to continue this until Sunday. Yesterday Mark got his Packages/Sources tool so far that we are about ready to ditch the old things, even though he took time to finalize my generate-release changes too. Not to speak about that database changes I wrote about in my last entry, which he now seems to have finally wrapped his brain around in a way to get those done. Short cite: good god, this will overhaul about all our code and database handling . And thats where he is currently working on too. He did draw a plenty complicated thats how it works onto the flip chart, and now seems to dump his brain into some form of python code. I m curious about the result, lets see. Torsten fixed up the code that generated the Maintainers and Uploaders files. The old code was just plain silly and took about 15 minutes just for the Uploaders file. It is now doing both of them in less than two. Of course there had been lots of bugfixes and code enhances too, not really good to list in a blog like this. My work, besides getting a bit sick in the evening, consisted of writing shell scripts to enable us and wanna-build admins to handle the keys needed for the automated signing of packages build on DSA maintained buildds. I have those ready now, so we are able to start doing the autosign stuff today/tomorrow. Phil - well, did whatever buildd related stuff he has to. Different place, I dont see much of it, but he has a blog himself, look over there.